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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the bearer data transport and bearer control protocols used between MGWs within the 
CS core network across the Nb Interface. The present document assumes that the implementation of the split of the call 
control and the bearer transport and control, as specified in 3GPP TS 23.205 [1] with BICC-based Nc, and in 3GPP TS 
23.231 [30] with SIP-I based Nc„ see figure 1. For BICC-based Nc, the User Plane protocol that uses this bearer data 
transport (Nb UP) is described in 3GPP TS 29.415 [3]. The transport format for the Nb interface with IP transport can 
optionally allow RTP multiplexing. Note that the present document does not preclude an implementation of a combined 
MSC Server and MGW. 
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Figure 1 : CS core network logical architecture 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AAL ATM Adaptation Layer 

AAL2 ATM Adaptation Layer Type 2 

AAL5 ATM Adaptation Layer Type 5 

AESA ATM End System Address 

ALC AAL2 Link Characteristics 

ARP Address Resolution Protocol 

ATM Asynchronous Transfer Mode 

AVP Audio Video Profile 

BICC Bearer Independent Call Control 

CN Core Network 

CSRC Contributing Source 

DSS2 Digital Subscriber Signalling 2 

IANA Internet Assigned Numbering Authority 

IP Internet Protocol 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 

IPBCP IP Bearer Control Protocol 

ITU-T International Telecommunications Union-Telecommunication sector 

I U F P Iu Framing protocol 

MGW Media GateWay 

MIME Multi purpose Internet Mail Extension 

MTP3b Message Transfer Part level 3 for Q.2140 [15] 

NNI Network Node Interface 

NSAP Network Service Access Point 

PDU Protocol Data Unit 

PVC Permanent Virtual Circuit 

RFC Request For Comment 

RTP Real-Time Transport Protocol 

RTCP Real-Time Transport Control Protocol 

SAR Segmentation and Reassembly 

SCCF-NNI Service Specific Coordination Function-Network Node Interface 

SDP Session Description Protocol 

SDU Service Data Unit 

SPVC Switched PVC 

SSSAR Service Specific Segmentation and Re-assembly sublayer 

SSCOP Service Specific Connection Oriented Protocol 

SSCS Service Specific Convergence Sublayer 

SSRC Synchronisation Source 

SVC Switched Virtual Circuit 

UDP User Datagram Protocol 

UNI User Network Interface 

UP User Plane 

VC Virtual Circuit 
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4 General 

The Nb UP shall be transported either over an ATM or IP bearer. 

5 Transport over ATM for BICC-based Nc 

5.1 General 

Clause 5 is only applicable in combination with BICC-based Nc. 

ATM shall be used in the transport network user plane and the transport network control plane according to ITU-T 
Recommendation 1.361 [6]. The structure of the ATM cell header used across the Nb interface shall be the cell header 
format and encoding at the NNI (see Figure 3 in 1.361 [6]). 

5.2 Transport network user plane 
5.2.1 General 

Figure 2 shows the ATM protocol stack used for the transport network user plane on the Nb interface. 



AAL-2 SAR SSCS (1.366.1) 



AAL2 (1.363.2) 



ATM 



Figure 2: ATM protocol stack used for the transport network user plane 

ATM AAL2 connections shall be transported over a VC which may either be a PVC, an SPVC or an SVC. For every 
ATM implementation of the Nb interface, a PVC shall be supported. The support of an SPVC or an SVC is optional. An 
ATM implementation may either support SPVCs only, SVCs only, or both. 

If SPVCs or SVCs are supported, DSS2 signalling [20] shall be used for the establishment and tear down of these VCs. 
The network element that generated a given switched VC shall be the only network element that is allowed to tear down 
thisVC. 

5.2.2 ATM Adaptation Layer 2 

5.2.2.1 AAL2-Segmentation and Reassembly Service Specific Convergence 
Sublayer 

Service Specific Segmentation and Reassembly (SSSAR) sublayer of ITU-T Recommendation 1.366.1 [9] shall be used 
for the segmentation and reassembly of AAL2 SDUs (i.e. only SSSAR is used from 1.366.1 [9]). 

5.2.2.2 AAL2-specification 

AAL2 shall be used according to ITU-T Recommendation 1.363.2 [7]. 

5.3 Transport network control plane 
5.3.1 General 

Figure 3 shows the protocol stack for the transport network control plane on the Nb interface. 
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Figure 3: ATM protocol stack for the transport network control plane 

Tunnelling, as described in 3GPP TS 23.205 [1], is currently not specified to transport the ATM transport network 
control plane. 

5.3.2 Signalling protocol 



5.3.2.1 



AAL2 Signalling Protocol 



ITU-T Q. 2630. 2 [19] shall be used for the establishment of AAL2 connections. The AAL2 transport layer uses the 
embedded E.164 [5] or AESA variants of the NSAP addressing formats [21]. Native E.164 addressing shall not be used. 

The MGW which issues a given ESTABLISH request [19] provides a Binding Reference (see 3GPP TS 23.205 [1]), 
This binding reference shall be copied into the SUGR parameter of the corresponding ESTABLISH request primitive 
[19]. 

The AAL2 Link Characteristics parameter (ALC) in the Establish Request message of the AAL2 signalling protocol 
shall be used. 

5.3.3 Signalling transport converter 

5.3.3.1 AAL2 MTP3B Signalling Transport Converter 

The AAL2 MTP3b Signalling Transport Converter shall be used according to ITU-T Recommendation Q.2 150.1 [16]. 

5.3.4 MTP3b 

MTP3b shall be used according to ITU-T Recommendation Q.2210 [17 & 18]. 

5.3.5 SSCF-NNI 

SSCF-NNI shall be used according to ITU-T Recommendation Q.2140 [15]. 

5.3.6 SSCOP 

SSCOP shall be used according to ITU-T Recommendation Q.2110 [14]. 



5.3.7 ATM Adaptation Layer Type 5 

AAL5 shall be used according to ITU-T Recommendation 1.363.5 [8] 
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Transport over IP for BICC based Nc 



6.1 General 

Clause 6 is only applicable in combination with BICC-based Nc. 

RTP (RFC 1889 [24] or RFC 3550 [29]) over UDP (RFC 768 [22]) over either IPv4 (RFC 791 [23]) or IPv6 (RFC 2460 
[27]) shall be used in the transport network user plane. The present specification takes the role of an RTP profile in 
describing the transport of the Nb UP protocol by RTP. Figure 4 shows the protocol stack for the transport network user 
plane on the Nb interface. 



RTP 



UDP 



IPv4 or IPv6 



Figure 4: IP Protocol stack for the transport network user plane 

Tunnelling, as described in 3GPP TS 23.205 [1], shall be used to transport the IP bearer control protocol IPBCP 
conform the ITU-T Recommendation Q.1970 "BICC IP Bearer Control Protocol" (IPBCP) (see 3GPP TS 29.205 [11]). 

6.2 Bearer Transport without multiplexing 

6.2.0 Introduction 

The support of bearer transport without multiplexing shall be supported. It shall be applied unless a bearer transport 
with multiplexing is negotiated via RTCP, as decribed in sub-clause 6.4.3. 

6.2.1 IP 

Either IPv4 (RFC 791 [23]) or IPv6 (RFC 2460 [27]) shall be used. 
One MGW may have several IP interfaces with different IP addresses. 

6.2.2 UDP 

The UDP Protocol (see RFC 768 [22]) shall be applied. 

Two consecutive port numbers shall be used at each MGW for the RTP bearer and for the optional RTCP connection 
that transport a single Nb UP connection. Two such consecutive port numbers are termed "port number block" in what 
follows. The first port number shall be even and shall be assigned to the RTP protocol. At a given MGW, the same port 
shall be used to send and to receive RTP PDUs. The next port number shall be assigned to the RTCP protocol. This port 
shall be reserved even if the optional RTCP protocol is not used. 

Each MGW shall administer the port numbers it intends to use for RTP/RTCP port number blocks. 

6.2.3 RTP 

RTP (see RFC 1889 [24] or RFC 3550 [29]) shall be applied. 

6.2.3.1 RTP Header 

The RTP Header Fields shall be used as described in the following subclauses: 
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6.2.3.1.1 Version 

RTP Version 2 shall be used. 

6.2.3.1.2 Padding 

Padding shall not be used. 

6.2.3.1.3 Extension 

The RTP Header shall not have an extension. 

6.2.3.1 .4 Contributing Source (CSRC) count 

There are zero CSRCs. 

6.2.3.1.5 Marker Bit 

The marker bit is ignored. 

6.2.3.1.6 PayloadType 

A dynamic Payload Type (see RFC 1890 [25]) shall be used. Values between 96 and 127 shall be used. The value shall 
be negotiated by means of the bearer control protocol. 

6.2.3.1 .7 Sequence Number 

The sequence number shall be supplied by the source MGW of a RTP PDU. The sink MGW of a RTP PDU may ignore 
the sequence number or it may use it to obtain statistics about the link quality and / or to correct out-of- sequence 
delivery, e.g. by dropping out-of- sequence packets. 

6.2.3.1.8 Timestamp 

The timestamp shall be supplied by the source MGW of a RTP PDU. A clock frequency of 16000 Hz shall be used. The 
definition of the RTP timestamp is specified in IETF RFC 1889 [24] which states that RTP timestamp is based on the 
sampling instant of the source encoder. However for the present application the source MGW is not mandated to set the 
RTP timestamp according to the sampling instant of the payload PDU. Although the RTP timestamp can reflect the 
sampling instant in some scenarios, the sink MGW cannot rely upon the accuracy of the RTP Timestamp. The sink 
MGW of a RTP PDU may ignore the timestamp. 

NOTE: An application can use the time based NbFP frame number to obtain end-to-end timing information. 

6.2.3.1 .9 Synchronisation Source (SSRC) 

The source MGW of a RTP PDU shall supply a SSRC. The sink MGW of a RTP PDU may ignore the SSRC if it does 
not use RTCP. 

6.2.3.1.10 CSRC list 

This list is empty. 

6.2.3.2 RTP Payload 

A single UP PDU, as described in 3GPP TS 29.415 [3], shall be transported as a RTP payload. 

6.2.4 RTCP 

RTCP (see RFC 1889 [24]) may be applied. The use of the RTCP protocol is optional. 
A MGW may ignore incoming RTCP PDUs. 



ETSI 



3GPP TS 29.414 version 8.2.0 Release 8 



13 



ETSI TS 129 414 V8.2.0 (2009-02) 



Figure 5 shows the protocol stack for the transport of RTCP. The above Sections about IP and UDP shall also apply for 
the transport of RTCP. 



RTCP 



UDP 



IPv4 or IPv6 



Figure 5: RTCP Protocol stack for the transport network user plane 



6.3 



Bearer Control Protocol 



The ITU-T Recommendation Q.1970 "BICC IP Bearer Control Protocol" (IPBCP) (see 3GPP TS 29.205 [11]) shall be 
applied. 

The use of Iu FP as RTP payload shall be indicated within IPBCP. IuFP shall transport either speech or data in a bearer 
independent way as described in 3GPP TS 23.205 and 3GPP TS 29.205. The negotiation of the type of payload within 
IuFP is outside the scope of IPBCP and described in the above specifications. 

NOTE: The IuFP is registered with IANA as the MIME type "VND. 3 GPP. IuFP "of the "audio" category, 
however, this registration does not preclude the use of IuFP to transport "data". 

6.3.1 Transport 

IPBCP shall be transported over the Mc and Nc interface by means of the ITU-T Recommendation Q.1990 "BICC 
Bearer Control Tunnelling Protocol" ( see 3GPP TS 29.205 [11]). The transport of the Q.1990 "BICC Bearer Control 
Tunnelling Protocol" on the Mc interface is described in 3GPP TS 29.232 [4]. The transport of the "BICC Bearer 
Control Tunnelling Protocol" on the Nc interface is described in ITU-T Recommendation Q.765.5 (see 3GPP TS 29.205 
[11]). 




Nc 



MSC-Server 



-Mc 



MGW 



Nb 



IPBCP: Q.1970 



Tunnel: Q.1990 



BICC: Q.765.5 



TS 29.232 



6.3.2 Procedures 



Figure 6: Transport of IPBCP 



The IPBCP procedures shall be used as described in the ITU-T Recommendation Q.1970 "BICC IP Bearer Control 
Protocol" (IPBCP) (see 3GPP TS 29.205 [11]). 
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6.3.2.1 Bearer Establishment 

The forward and backward RTP bearers used to transport one Nb UP connection shall be set up together after an IPBCP 
handshake with a Request message and an Accepted message has succeeded. 

Each MGW shall signal its peer MGW with the RTP port number. The RTCP port number shall be the next higher 
number. 

If the optional 20 ms packetisation time is supported for PCM encoded speech over Nb and if its use is authorized by 
local configuration setting, the MGW shall also negotiate with its peer MGW the packetisation time to be used for PCM 
encoded speech over Nb, even if the codec configured on the bearer is still unknown or differs from PCM. This is done 
by including the "pcmptime=20" parameter in the IPBCP Request as defined in sub-clause 6.3.3.5. A MGW receiving 
the "pcmptime=20" parameter ignores it if the 20 ms packetisation time is not supported for PCM encoded speech over 
Nb. A MGW receiving the "pcmptime=20" parameter shall return the "pcmptime=20" parameter in the IPBCP Accept 
message only if the 20 ms packetisation is supported for PCM encoded speech over Nb and if its use is authorized by 
local configuration setting. Receipt of the "pcmptime=20" parameter in the IPBCP Accept shall indicate to the 
originating MGW that it shall apply the 20 ms packetisation time when PCM encoded speech is sent over the Nb bearer. 
Otherwise the default 5 ms packetisation time shall be used for PCM encoded speech over Nb. The result of the 
negotiation is only used if PCM is selected on the bearer. 

6.3.2.2 Bearer Modification 

A modification of existing RTP bearers is not permitted. The IPBCP Request message shall not be used to modify 
bearers. 

6.3.2.3 Bearer Release 

When the H.248 Termination [10] of an Nb UP connection on a MGW is deleted by means of signalling over the Mc 
interface, which are outside the scope of IPBCP (see 3GPP TS 29.232 [4]), the used resources shall be freed as follows: 

The MGW shall discard any packets arriving at the port pair used for the old Nb UP connection until it sets up a new 
Nb UP connection on these ports. The MGW shall only reuse these ports after a time that is long enough to avoid that 
packets from the old connection still arrive. 

6.3.3 Use of IPBCP message fields 

The IPBCP message fields shall be used as described in the ITU-T Recommendation Q.1970 "BICC IP Bearer Control 
Protocol" (IPBCP) (see 3GPP TS 29.205 [11]) and SDP (RFC 2327 [26]). Moreover, the following subclauses shall be 
applied: 

6.3.3.1 Origin 

<address> shall be the IP address assigned to the IP interface used for the RTP bearer on the source MGW of the 
present IPBCP message. 

6.3.3.2 Session Name 

The source MGW shall supply an arbitrary string as < session name>. The sink MGW shall ignore this string. 

6.3.3.3 Connection Data 

The <connection address> shall be identical to the above origin <address> 

6.3.3.4 Media Announcement 

<media> shall always be set to "audio" irrespective of the payload type within IuFP. 

<port> shall be set to the port number assigned to the RTP bearer on the source MGW of the present IPBCP message 

<transport> shall be set to "RTP/AVP". 
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<fmt list> shall be set to the chosen dynamic payload number. The MGW that initiates the bearer establishment may 
choose any value between 96 and 127. The peer MGW shall echo this value. 

6.3.3.5 Media Attributes 

The following media attribute shall be supplied: "a=rtpmzp:<dynamic payload number> VND.3GPP.IUFP/16000", 
where: <dynamic payload number> is the same dynamic payload type number as in the above media announcement 
<fmt list>. 

The media attribute "a=fmtp:<format> pcmptime=20" shall also be set: 

- in the IPBCP Request if the optional 20 ms packetisation time is supported for PCM encoded speech over Nb 
and if its use is authorized by local configuration setting; 

- in the IPBCP Accept message if received in the IPBCP Request and if the optional 20 ms packetisation time is 
supported for PCM encoded speech over Nb and if its use is authorized by local configuration setting. 

Other media attributes shall not be used. They shall be ignored in the MGW receiving an IPBCP message. 

Example of IPBCP Request / Accept exchange where both MGWs support the 20 ms packetisation time for PCM 
encoded speech over Nb: 

IPBCP Request (MGW1 -> MGW2) 

m=audio 49170 RTP/AVP 97 

a=rtpmap:97 VND.3GPP.IUFP/16000 

a=fmtp:97 pcmptime=20 
IPBCP Accept (MGW2 -> MGW1) 

m=audio 49320 RTP/AVP 97 

a=rtpmap:97 VND.3GPP.IUFP/16000 

a=fmtp:97 pcmptime=20 

6.4 Bearer Transport with multiplexing 
6.4.1 Introduction 

This sub-clause specifies an optional transport format for the Nb interface and IP transport that allows transporting 
several RTP/NbFP/codec payload PDUs of different user plane connections within one packet, and the corresponding 
backward compatible signalling extensions required to negotiate the use of this transport option. Use of this transport 
format saves bandwith in the IP network (bandwidth gains are evaluated in 3GPP TR 29.814 [28]). 

Band with saving is achieved by multiplexing several NbFP PDUs within one UDP/IP packet. As an option, the RTP 
header may be compressed in addition. Two transport formats are specified accordingly. 



6.4.2 Transport format 



6.4.2.1 IP 

Either IPv4 (RFC 791 [23]) or IPv6 (RFC 2460 [27]) shall be used. 
One MGW may have several IP interfaces with different IP addresses. 

6.4.2.2 UDP 

The UDP Protocol (see RFC 768 [22]) shall be applied. If multiplexing is applied with or without header compression, 
the source UDP port number shall indicate the local termination used to combine the multiplexed packet and the 
destination UDP port number shall indicate the remote port number where PDUs are demultiplexed. The negotiation if 
multiplexing is applied and of the destination UDP port is described in sub-clause 6.4.3. If multiplexing was negotiated 
for a Nb UP user plane connection, the MGW may apply multiplexing by sending all packets of the user plane 
connection towards the negotiated destination UDP port. 
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6.4.2.3 



Transport Format for multiplexing without RTP Header Compression 



Several RTP/NbFP/codec payload PDUs sent to the same IP address are multiplexed within one single UDP/IP packet 
over the Nb interface between MGWs. If DiffServ is applied, all multiplexed PDUs also need to share the same Diffserv 
class. The multiplexing shall only be used with RTP packets. RTCP shall be transported normally by UDP/IP packets. 

Use of multiplexing shall be negotiated between MGWs, as specified in sub-clause 6.4.3. 

Before each multiplexed RTP/NbFP/codec payload PDU inserted into the UDP/IP packet a multiplexing header, which 
identifies the multiplexed packet, shall be inserted. 
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Figure 7: UDP/IP Packet with multiplexed RTP/NbFP payload PDUs without RTP header compression 

The multiplexing header includes : 

- RT bit. 

The field has two possible values, for indicating full packet and 1 for indicating compressed packet. Value 
shall be used for an uncompressed RTP header, as decribed in the present sub-clause. 

- Mux ID, 15 bits. 
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For identification of different user plane connections. The value shall be the UDP destination port of the 
corresponding non-multiplexed RTP/NbFP PDU packet divided by two (only even numbered ports are used for 
RTP sessions). 

- Length Indicator (LI), 8 bits. 

Gives the length of the multiplexed RTP/NbFP PDU packet (RTP header + RTP Payload = RTP header + NbFP 
header + NbFP payload) in bytes (the last byte of the RTP/NbFP PDU is padded to the next byte boundary if 
necessary). Maximum length is 256 bytes. LI gives the information where the next multiplexed packet starts. 

- R bit. 

Reserved for future use. Shall be set to by the sending entity and be ignored by the receiving entity. 

- Source ID, 15 bits. 

For identification of the different connections. The value shall be the source UDP port of the corresponding non- 
multiplexed NbFP/codec PDU packet divided by two (only even numbered ports are used for RTP sessions). 
This information is transferred to permit the receiving node to optionally detect and filter illegitimate packets 
(e.g. packets received from the peer termination precedingly associated to the receiving termination). 

The multiplexed RTP/NbFP payload PDU shall be inserted in the IP/UDP packet directly after the corresponding 
multiplexing header. The multiplexed RTP/NbFP payload PDU shall follow the rules in sub-clause 6.2.3 and consists of 
the full RTP header, the full NbFP header and the NbFP payload. If the multiplexed RTP/NbFP payload PDU does not 
end at a byte boundary, its last byte shall be padded with zeros. 

The multiplexing method does not limit the number of packets being multiplexed and it is thus the data link layer 
protocol that defines the maximum frame size. E.g. an IP datagram has a maximum length of 65 535 bytes and Ethernet 
1518 bytes. In order to avoid additional delay in the network the packets should not be delayed more than 1 ms to 2 ms, 
which also effectively limits the number of multiplexed packets and makes the multiplexing -jitter low. 
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Figure 8: Example of multiplexed packet with two RTP frames 
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6.4.2.4 Transport Format for multiplexing with RTP header compression 

To achieve even better bandwidth savings, the RTP header may optionally be compressed. This is possible since the 
RTP header includes many static fields that remain unchanged during an RTP session if NbFP is used as payload (see 
sub-clause 6.3.2). 

Use of RTP header compression shall be negotiated between MGWs, as specified in sub-clause 6.4.3. 

At least the first two RTP packets of each RTP session shall be sent with their full RTP header to allow the receiver to 
store the full header and use it in decompression. RTP packets shall also be sent with their full RTP header till receipt of 
a RTCP packet from the peer indicating support of RTP header compression. Subsequent packets may be sent with a 
compressed RTP header. If a MGW does not receive any of the initial RTP packets with a full RTP header, the MGW 
shall assume that the fields of the RTP header other than those present in the compressed RTP header are set as defined 
in sub-clause 6.2.3.1, and shall therefore not consider this as an error. 



Before each multiplexed RTP/NbFP/codec payload PDU inserted into the UDP/IP packet a multiplexing header, which 
identifies the multiplexed packet, shall be inserted 
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Figure 9: UDP/IP Packet with multiplexed RTP/NbFP payload PDUs with RTP header compression 

The multiplexing header shall be used as described in sub-clause 6.4.2.3. However, the T bit shall be set for a 
compressed RTP header, as decribed in the present sub-clause. The Length Indicator gives the length of the multiplexed 
RTP/NbFP PDU packet in bytes (compressed RTP header + RTP Payload ). 

The multiplexed RTP/NbFP payload PDU shall be inserted in the IP/UDP packet directly after the corresponding 
multiplexing header. The multiplexed RTP/NbFP payload PDU shall consist of the compressed RTP header described 
below followed by the full NbFP header and the NbFP payload, as described in 3GPP TS 29.415 [3]. If the multiplexed 
RTP/NbFP payload PDU does not end at a byte boundary, its last byte shall be padded with zeros. 

The compressed RTP header shall include the following two fields taken from the uncompressed RTP header: 

- Sequence number (SN), 8 bits. 

The field changes as the original sequence number (RFC 3550 [29]) but is shortened from 16 bits to 8 bits (256 
packets). The least significant byte of the RTP sequence number shall be included. Sub-clause 6.2.3.1.7 is 
applicable. 
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- Timestamp (TS), 16 bits. 

The TS field changes as the original timestamp (RFC 3550 [29]) but the length is half of the original resulting in 
modulo of 4 seconds with 16 kHz clock reference. The least significant two bytes of the RTP timestamp shall be 
included. Sub-clause 6.2.3.1.8 is applicable. 

NOTE: These RTP fields change during a connection and thus need to be transferred within each packet for NbFP 
payload. All other RTP fields do not change (see sub-clause 6.2.3). 



IP ( 20 / 40 bytes ) 


UDP ( 8 ) 


Compr. RTP ( 3 ) 
MUX (5 ) NbUP frame ( 9. . . ) 


Compr. RTP ( 3 ) 
MUX (5 ) NbUP frame ( 9. . . ) 


















Common heac 


-/ 






1. MUX packet 






2. MUX packet 



Negotiated 
UDP MUX 
port 



Figure 10: Example of multiplexed packet with two RTP frames and compressed RTP headers 

6.4.3 RTCP 



6.4.3.1 



General 



A MGW wishing to apply Bearer Transport with multiplexing shall use RTCP (see RFC 3550 [29]) to negotiate 
multiplexing. 

RTCP shall be used separately for each user plane connection. RTCP shall be transported by UDP/IP packets as 
described in sub-clause 6.2.4. and not included included in IP/UDP packets using the multiplexing format described 
above. 



6.4.3.2 



Multiplex negotiation via RTCP 



RTCP shall be used to negotiate the use of multiplexing. A new 3GPP-specific RTCP Multiplexing packet is specified 
in sub-clause 6.4.3.3 for this purpose, and may be added to compound RTCP packets following the principles of RFC 
3550 [29]. The Multiplexing RTCP packet indicates: 

if multiplexing without RTP header compression is supported ; 

- if multiplexing with RTP header compression is supported ; 

- the local UDP port where to receive multiplexed data streams, 

- if multiplexing is selected.. 

When setting up a new user plane connection, both peer MGWs of a NbUP connection shall start to send data without 
applying multiplexing and may indicate their readiness to receive multiplexed data streams by including the new RTCP 
Multiplexing packet in the initial and all subsequent RTCP packets they send. A MGW shall always announce the same 
multiplexing capabilities and the same UDP port where to receive multiplexed data streams in all the RTCP 
Multiplexing packets it sends for a given RTP session. MGWs should preferably send their initial RTCP packet at the 
very beginning of the RTP session to be able to apply multiplexing as soon as possible. A MGW sending a Multiplexing 
packet indicating support of multiplexing shall be ready to receive multiplexed packets at the announced UDP port. A 
single UDP port for multiplexing shall be used per destination IP address. 

A MGW receiving an RTCP packet, where the peer indicated its readiness to receive multiplexed data streams, may 
apply multiplexing to send the corresponding RTP data streams towards the sender of the RTCP packet. If the MGW 
decides to apply multiplexing, it can immediately start sending multiplexed data streams towards the corresponding 
UDP multiplexing port announced in the received RTCP Multiplexing packet. The MGW shall indicate in subsequent 
RTCP Multiplexing packets if it applies multiplexing with or without header compression for the given user connection 
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A MGW that does not receive RTCP or receives RTCP without the RTCP Multiplexing packet shall continue to send 
data for the user connection without applying multiplexing. 

A MGW that does not support multiplexing will ignore the unknown received RTCP Multiplexing package according to 
RTCP procedures and will continue to send data for the user connection without applying multiplexing. 

Sending of a RTCP Multiplexing packet indicating readiness to receive multiplexed data streams does not necessarily 
mean that the MGW is ready to send multiplexed data streams, i.e. multiplexing may be applied on a single or on both 
directions for a given RTP session. 

The applicable compressed header format is not negotiated using RTCP, but is determined by the fact if the Nb bearer is 
controlled via a SIP-I based Nc interface or a BICC based Nc interface. A MGW may support multiplexing of both RTP 
header compression formats on a same IP interface. 



6.4.3.3 RTCP Multiplexing packet 

The format of the RTCP Multiplexing packet is specified in figure 1 1 . 



Bits 


o => 
So 




7 


6 


5 


4 


3 


2 


1 







V=2 


P 


subtype 


1 


APP packet 
header 


PT=APP=204 


1 


Length 


2 


SSRC/CSRC 


4 


Name(ASCII) 


4 


MUX 


CP 


Selection 


Reserved=0000 


2 


Application 
dependent 
data 


Reserved=00000000 


Reser 
ved=0 




Local MUX UDP port/ 2 


2 



















Figure 11: RTCP Multiplexing packet 

The APP packet header includes : 

- version (V), 2 bits 

Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. RTP Version 2 shall be 
used. 

- padding (P), 1 bit 

As specified in RFC 3550 [4]. 
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- subtype, 5 bits. 

The following subtype value shall be used : 
00001 : RTCP Multiplexing packet 

- packet type (PT), 8 bits. 

Shall contains the constant 204 to identify this as an RTCP APP packet 

- length, 16 bits. 

As specified in RFC 3550 [4]. The length of this RTCP packet in 32-bit words minus one, including the header 
and any padding. (The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a 
compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.) 

- SSRC/CSRC, 32 bits. 

As specified in RFC 3550 [4]. 

- name, 32 bits. 

Shall be set to "3GPP" 

The application-dependent data includes : 

- multiplexing bit (MUX), 1 bit 

Indicates whether multiplexing without RTP header compression is supported or not by the sender of the RTCP 
packet : set to if not supported, set to 1 if supported. 

- multiplexing with RTP header compression bit (CP), 1 bit 

Indicates whether multiplexing with RTP header compression is supported or not by the sender of the RTCP 
packet : set to if not supported, set to 1 if supported. 

- Selection bits, 2 bits 

Indicates whether the sender of the RTCP packet has selected to apply multiplexing with or without header 
compression for the user plane packets that it sends on this connection. The following values are defined: 

00: no multiplexing is applied 

01: multiplexing is applied without RTP header compression 

10: multiplexing is applied with RTP header compression 

1 1 : reserved 

- Local MUX UDP port, 15 bits : 

Local UDP port where the sender demands to receive multiplexed data streams. The value shall be the same as 
the local MUX UDP port divided by two. This parameter shall be ignored by the receiver of the RTCP 
Multiplexing packet if the MUX and CP bits indicate that multiplexing is not supported. 

- Reserved bits: 

Extension bits may be added in the RTCP Multiplexing packet in future releases. Reserved bits shall be set to 
in sent RTCP Multiplexing packet of this relaese and shall be ignored in incoming RTCP Multiplexing packets. 

Extension fields may be added in the RTCP Multiplexing packet in future releases. They shall be ignored by a MGW 
implementing an earlier version of the specification. 
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Transport over IP for SIP-I based Nc 



7.1 General 

Clause 7 is only applicable in combination with SIP-I based Nc. 

IPv4 (RFC 791 [23]) shall be supported. IPv6 (RFC 2460 [27]) may be supported. 

RTP (RFC 1889 [24] or RFC 3551 [29]) over UDP (RFC 768 [22]) over either IPv4 (RFC 791 [23]) or IPv6 (RFC 2460 
[27]) shall be used in the transport network user plane. Figure 4 in Clause 6.1 shows the protocol stack for the transport 
network user plane on the Nb interface. 

7.2 Bearer Transport without multiplexing 

7.2.0 Introduction 

See 6.2.0 

7.2.1 IP 

See 6.2.1 

7.2.2 UDP 

See 7.2.2 

7.2.3 RTP 

RTP (see RFC 1889 [24] or RFC 3550 [30]) shall be applied. 

7.2.3.1 RTP Header 

The RTP Header Fields shall be used as described in the following subclauses: 

7.2.3.1.1 Version 

RTP Version 2 shall be used. 

7.2.3.1.2 Padding 

Padding shall not be used. 

7.2.3.1.3 Extension 

The extension bit shall be used as specified for the RTP profile applicable for the used payload. 

7.2.3.1 .4 Contributing Source (CSRC) count 

There are zero CSRCs. 

7.2.3.1.5 Marker Bit 

The marker bit shall be used as specified for the RTP profile applicable for the used payload. 
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7.2.3.1.6 PayloadType 

The payload type shall be set as negotiated by means of SIP-I and supplied over the Mc interface. 

7.2.3.1 .7 Sequence Number 

The sequence number shall be supplied by the source MGW of a RTP PDU. 

7.2.3.1.8 Timestamp 

The timestamp shall be supplied by the source MGW of a RTP PDU. 

7.2.3.1 .9 Synchronisation Source (SSRC) 

The source MGW of a RTP PDU shall supply a SSRC. 

7.2.3.1.10 CSRCIist 

This list is empty. 

7.2.3.2 RTP Payload 

Speech in various encodings packed in corresponding RTP payload types may be transported as RTP Payload, as 
further specified in TS 26.102 [32]. Data and fax packed in corresponding RTP payload types may also be transported 
as RTP Payload, as further specified in 3GPP TS 29.007 [36]. 

NOTE: The Nb framing protocol specified in 3GPP TS 29.415 [3] is not applicable. 

7.2.4 RTCP 

The use of the RTCP (see RFC 1889 [24] or RFC 3551 [29]) protocol is optional, unless the RTP payload profile of the 
transported payload requires RTCP. 

A MGW may ignore incoming RTCP PDUs, unless the RTP payload profile of the transported payload requires some 
usage of RTCP 

Figure 5 in Clause 6.2.4 shows the protocol stack for the transport of RTCP. The above Sections about IP and UDP 
shall also apply for the transport of RTCP. 

7.3 Bearer Transport with multiplexing 

7.3.1 Introduction 

See Clause 6.4.1 

7.3.2 Transport format 

7.3.2.1 IP 

See Clause 6.4.2.1 

7.3.2.2 UDP 

See Clause 6.4.2.2 

7.3.2.3 Transport Format for multiplexing without RTP Header Compression 

See Clause 6.4.2.3. 
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However, instead of RTP/NbFP/codec payload PDUs, RTP/codec payload PDUs shall be transported. The RTP header 
and the RTP payload shall follow the rules in sub-clause 7.2.3. 

7.3.2.4 Transport Format for multiplexing with RTP header compression 

RTP header compression for Nb bearers with SIP-I based Nc shall be applied as specified in sub-clause 6.4.2.4 for Nb 
bearers with BICC-based Nc, with the exceptions specified in the present Clause. 

The transport format additionally includes the marker bit (bit M) and the payload type (PT), which can very dependent 
on the transported payload. 
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Figure 12: UDP/IP Packet with multiplexed RTP/Nb payload PDUs with RTP header compression 
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The compressed RTP header shall include the following fields taken from the uncompressed RTP header: 

Sequence number (SN), 8 bits. 

Timestamp (TS), 16 bits. 

Marker bit (M), 1 bit. 

- Payload Type (PT), 7 bits 

The usage of these header fields shall follow Clause 7.2.3 

The Transport Format for multiplexing with RTP header compression shall not be applied for RTP payload types that 
use an RTP header extension. For RTP payload types that use an RTP header extension, this transport format shall not 
be offered or accepted in the RTCP multiplexing negotiation. 

7.3.3 RTCP 

See Clause 6.4.3 

7.4 Transcoder-less Interworking with the lu Framing Protocol 
7.4.1 Introduction 



Transcoder-less 

user plane 

interworking 



RTP 



UDP 



IP 



L2 



LI 



IuFP 



L3 



L2 



LI 



Nb 



MGW 



lu 



Figure 13: Transcoder-less Interworking between IuFP and RTP (optional in the event the codecs on 

both sides are the same) 

If no transcoder is inserted, the MGW shall interwork the procedures between the RTP at the Nb interface of the SIP-I 
based CS CN and the lu framing protocol (see 3GPP TS 25.415 [31]) at the lu interface as described in the following 
Clauses. 

7.4.2 Initialisation 

There is no need to interwork IuFP initialisation procedures between lu interface and the RTP at the Nb interface of the 
SIP-I based CS CN. 

7.4.3 Time alignment 

The purpose of the time alignment procedure on the lu interface is to minimise the buffer delay in the RNC for 
downlink transmissions by adjusting the vocoder time reference within the network. No such procedure exists within 
RTP, so the MGW shall return NACK indication time alignment not supported according to 3GPP TS 25.415 [31]. 
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7.4.4 Rate control 

The rate control procedure signals to the peer entity the maximum rate among the currently allowed rates at which it can 
receive codec frames. Rate control only applies to AMR family codec configurations with multiple active modes. On 
the Iu interface, IuFP provides for rate control via the exchange of RATE CONTROL and RATE CONTROL ACK 
PDUs. On the Nb interface of the SIP-I based CS CN, RFC 4867 [35] provides for in-band rate control via the Codec 
Mode Request (CMR) field of every codec frame. 

Interworking of rate control procedures at an MGW between an Nb interface and a corresponding Iu interface only 
applies when the MGW bridges compatible codec configurations between the interfaces without applying a transcoding 
function. An MGW receiving a CMR from an Nb interface shall initiate the IuFP rate control procedure on the 
corresponding Iu interface. An MGW receiving a rate control request on an Iu interface shall adjust the CMR field of 
outgoing speech frames on the corresponding Nb interface. 

7.4.5 Frame quality indication 

The Iu framing protocol signals frame quality with the Frame Quality Classification (FQC) field of each speech frame 
PDU. See 3GPP TS 26.102 [32] and 3GPP TS 25.415 [31] for details. The FQC may have possible values: 
0=frame_good; l=frame_bad; 2=frame_bad_due_to_radio; and 3=spare. The RTP AMR payload at the Nb interface 
signals frame quality with the Q bit (frame quality indicator) field of each speech frame, as defined in RFC 4867 [35]. 
The Q bit may have values: l=speech_good; and 0=speech_bad or sid_bad. 

Tables 1 and 2 provide the mapping between Nb and Iu interfaces. 

Table 1 : Mapping of Nb AMR RTP profile Qbit onto Iu FQC 



Nb AMR RTP profile Qbit 


Nb AMR RTP profile FT 


Iu - FQC 


1 


X 








X 


1 



Table 2: Mapping Iu FQC onto Nb AMR RTP profile Qbit 



Iu - FQC 


Nb AMR RTP profile Qbit 


Nb AMR RTP profile FT 





1 


NC 


1 





NO DATA 


2 





NC 



7.4.6 Framing 

Even when the MGW bridges compatible codec configurations between the Nb and Iu interfaces, the MGW shall 
perform translation between the frame formats defined for the two interfaces, since all codec configurations have 
different framing procedures for the two interfaces. The framing details for Iu are defined in 3GPP TS 26.102 [32] and 
3GPP TS 25.415 [31], although they do not describe the framing for ITU-T codecs other than G.711. The framing 
details for Nb are defined in RFC 4867 [35], RFC 3550 [29], RFC 3551 [33] and RFC 3555 [34]. 

7.4.7 Transcoding 

Transcoding at the MGW is avoided when the MGW bridges compatible codec configurations between the Nb and Iu 
interfaces. Otherwise transcoding is necessary, which eliminates the need to interwork other user plane procedures 
between the interfaces. 

7.4.8 Discontinuous transmission 

When the MGW bridges compatible codec configurations between the Nb and Iu interfaces, the DTX procedures are 
normally interworked transparently by translating between the framing formats on the interfaces. All the ITU-T and 
AMR family codecs have configurations that are compatible between the Iu and Nb interfaces. 
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7.4.9 Timing and sequence information 



The MGW shall always correct out-of- sequence delivery between Nb and Iu interfaces, either by re-ordering frames, or 
by dropping frames that are out of sequence. 

When the IuFP frame numbers are based on time and if the MGW bridges compatible codec configurations between the 
Nb and Iu interfaces, it shall either correct jitter before forwarding PDUs or interwork the RTP timestamp (see RFC 
3550 [29]) with the IuFP Frame Number (see 3GPP TS 25.415 [31]) so that both the RTP timestamp and IuFP frame 
number similarly reflect the nominal sampling instant of the user data in the packet. 

NOTE: Correcting jitter may cause additional delay. 

The RTP sequence number (see RFC 3550 [29]) is handled independently on Nb, i.e. it is not interworked with the IuFP 
Frame Number (see 3GPP TS 25.415 [31]). 



ETSI 



3GPP TS 29.414 version 8.2.0 Release 8 



29 



ETSI TS 129 414 V8.2.0 (2009-02) 



Annex A (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


03-2001 


TSG#1 1 


NP-010215 






Approved as Version 4.0.0 to be placed under Change Control 


2.1.0 


4.0.0 


06-2001 


TSG#12 


NP-010257 


001 




Editorial Clarifications in 29.414 and IANA registration 


4.0.0 


4.1.0 


09-2001 


TSG#13 


NP-010439 


003 


2 


Transport of data in the luFP 


4.1.0 


4.2.0 


12-2001 


TSG#14 


NP-010573 


004 




Correction of inconsistency regarding RTP clock frequency 


4.2.0 


4.3.0 


12-2001 


TSG#14 


NP-010573 


005 


1 


Correction to Scope clause 


4.2.0 


4.3.0 


03-2002 


TSG#15 


NP-020082 


006 




Update Reference to I.363.2 


4.3.0 


4.4.0 


03-2002 


TSG#15 


NP-020085 


007 




Add GERAN lu mode to scope 


4.3.0 


5.0.0 


04-2004 


TSG#26 








Upgraded to v6.0.0 


5.0.0 


6.0.0 


12-2005 


TSG#30 


CP-050517 


018 


2 


20 ms packetisation time for PCM coded speech over IP Nb 


6.0.0 


7.0.0 


12-2006 


TSG#34 


CP-060620 


026 


2 


RTP Timestamp 


7.0.0 


7.1.0 


03-2007 


TSG#35 


CP-070106 


027 


3 


Multiplexing at Nb interface with IP transport 


7.1.0 


7.2.0 


03-2008 


TSG#39 


CP-080044 


033 


2 


Adding RTP Transport used by SIP-I 


7.2.0 


8.0.0 


05-2008 


TSG#40 


CP-080308 


034 


2 


Mandatory support of Ipv4 on SIP-I based Nb interface 


8.0.0 


8.1.0 


05-2008 


TSG#40 


CP-080309 


035 


2 


Framing Protocol Interworking 


8.0.0 


8.1.0 


12-2008 


TSG#42 


CP-080754 


036 


1 


Reference to RTP poayload types 


8.1.0 


8.2.0 



ETSI 



3GPP TS 29.414 version 8.2.0 Release 8 



30 



ETSI TS 129 414 V8.2.0 (2009-02) 



History 



Document history 


V8.2.0 


February 2009 


Publication 



























ETSI 



